In modern authoring environments, development work for complex software systems can be done in parallel by a number of development teams around the world. Each development team may work on discrete portions of the system's overall functionality. The teams may work largely independently, in geographically diverse areas of the world, which renders day-to-day consultations between the teams impractical. Although the development teams may develop their sub-systems from a common high level design document, the team's design efforts may not be synchronized. At some point during development, however, the various teams' developments must be merged together and perhaps additional functionality will be developed based on the merged code.
The act of merging software developments from several independent design teams entails substantial expense. This dependency between the teams can hamper efficiency and code stability, among other issues. Further, there exists a fundamental dependency upon the code lines of the foundation or basic development team forming the base of the software program.
For example, FIG. 1 illustrates a current approach of software development in a distributed environment. As shown at box 101, the code of a foundation team, for example, includes procedure oriented code segments which are statements and function calling. During cluster functionality enhancement, modifications by one or more globalization teams, for example, are added to the procedure oriented code segments of the foundation team. The new code is mixed with the original code, as shown at box 102. Errors often arise when merging code, and functionality conflicts among code from different teams are essentially inevitable when synchronizing the codes.
In addition, in the example of FIG. 1, the source code for the new functions from the different globalization teams is embedded into the source code of the foundation team. Further, there is no unified mechanism for managing all new codes of a specific cluster.
In such situations, a procedure oriented interface and a subroutine called directly through the name of its interface are used to handle code integration and resulting conflicts as shown at boxes 103 and 104. This solution, however, is inefficient, prone to error, and inflexible. If the name of an interface is changed, everything referencing the interface must be modified, resulting in a huge workload and potential for error. Further, even if a logic enhancement is made, the caller cannot call the enhancement automatically.
Thus, it would be desirable to introduce a unified mechanism for managing codes from different sources or entities in a distributed software development environment.